Let Digiqt design atomic settlement architecture, cash leg options, and the failure paths that decide whether it works.

Both Legs Or Neither

# Making Both Legs Move Together, or Neither Move at All

Delivery-versus-payment is not a new idea and atomic settlement is not a new objective. Securities settlement systems have managed principal risk for decades by ensuring that delivery and payment either both happen or neither does. What distributed ledger technology changes is the mechanism, the timing, and crucially the range of things that can be settled against each other.

That makes the engineering question narrower and more interesting than the usual framing suggests. Designing atomic settlement DvP DLT systems is mostly about two decisions: what the cash leg is, and what happens when something fails halfway. The distributed ledger part is the easier half.

## What problem does atomic settlement actually solve?

Principal risk, meaning the exposure created when one party performs and the other does not.

In a non-simultaneous exchange, one side delivers securities and waits for cash, or pays and waits for delivery. In between, the full value is at risk. Existing infrastructure addresses this through central securities depositories and settlement systems that coordinate both legs, which is why the CPMI-IOSCO Principles for financial market infrastructures, published in April 2012, apply to central securities depositories and securities settlement systems alongside payment systems, central counterparties, and trade repositories. Tokenisation offers a different route to the same objective, potentially with a shorter cycle and a wider set of assets.

### What does atomicity add over existing DvP?

Composability and timing, rather than a fundamentally new guarantee.

The material gains are that settlement can occur continuously rather than in cycles, that assets not currently served by an efficient depositary can participate, and that settlement can be composed with other actions in one transaction, such as a repo leg or a collateral substitution. Be precise about which of those benefits you are pursuing, because a programme justified as removing principal risk is solving a problem existing infrastructure already handles for mainstream instruments.

> **Which specific benefit is your tokenisation programme pursuing: timing, asset coverage, or composability?**
>
> [Talk to Digiqt about atomic settlement design objectives](https://digiqt.com/contact-us/)

## What are the architectural options?

Four, with a clear trade-off between coordination complexity and platform reach.

| Option | How it works | Strength | Weakness |
|---|---|---|---|
| Single ledger, both legs | Cash and asset tokens on one platform, one transaction | Simplest atomicity, no protocol needed | Requires both on the same platform |
| Cross-ledger with hash-locked contracts | Conditional locks with a shared secret and timeouts | Works across platforms | Timeout risk, liquidity locked, complexity |
| Cross-ledger with a trusted coordinator | A coordinating party sequences both legs | Simpler than cryptographic protocols | Reintroduces a trusted intermediary |
| Hybrid with existing payment system | Asset leg on ledger, cash leg via RTGS with confirmation | Uses proven cash infrastructure | Not truly atomic, needs bridging design |

### Why is single-ledger both simplest and hardest?

Because atomicity is free within one transaction and getting cash onto the platform is the whole problem.

If tokenised cash and tokenised assets exist on the same ledger, delivery-versus-payment is one atomic state transition with no coordination protocol, no timeout, and no partial state. Every other option exists because that condition is difficult to satisfy, since the cash leg needs to be something participants accept as settlement. That is why the interesting experimentation focuses on putting central bank and commercial bank money onto shared platforms rather than on the settlement mechanics themselves.

### What are the trade-offs of hash-locked approaches?

They work without a trusted coordinator and they impose timeout risk and locked liquidity.

Conditional locks release both legs on revelation of a secret, with timeouts to unwind if it never arrives. That achieves atomicity across platforms and introduces new operational realities: assets are locked while the protocol runs, timeouts create a window where one party can choose whether to proceed based on market movement, and the failure path leaves participants with unwound trades they need to re-execute. Those are manageable and they are real, and they should be modelled operationally rather than treated as protocol detail.

## What is the cash leg, and why is it the real decision?

Because it determines the legal character of settlement, the operating hours, and who bears what risk.

| Cash leg | Character | Considerations |
|---|---|---|
| Tokenised central bank money | Settlement in central bank money | Availability depends on central bank arrangements |
| Tokenised commercial bank deposits | Claim on a bank | Credit and concentration considerations, bank issuance |
| Regulated stablecoin | Claim on an issuer with reserves | Redemption, reserve quality, run risk |
| Off-ledger payment with on-ledger confirmation | Existing rails plus a bridge | Not atomic, operating hours constrain settlement |

The choice is not primarily technical. Settling against a claim on a commercial bank is economically different from settling against central bank money, and both differ from settling against an issuer's stablecoin. Take that analysis to treasury, risk, and legal before selecting a platform, because retrofitting a different cash leg late is close to a rebuild. The design of the bank-issued options is the subject of [tokenised deposits and stablecoin infrastructure](https://digiqt.com/blog/tokenized-deposits-stablecoin-infrastructure/).

## What does live experimentation actually show?

That multi-currency atomic settlement with tokenised reserves and deposits works, at modest scale and useful speed.

The BIS Innovation Hub's Project Agorá, a public-private collaboration involving eight central banks and more than forty financial institutions, is testing a multi-currency shared programmable platform for wholesale cross-border payments, combining tokenised central bank reserves with tokenised commercial bank deposits to enable atomic settlement. Its real-value testing in July 2026 involved 28 institutions completing approximately CHF 800,000 in transactions across multiple currencies, with average settlement of approximately 80 seconds from initiation, covering payment-versus-payment among other use cases, and demonstrating interoperability with existing real-time gross settlement and core banking systems using ISO 20022.

### What does 80 seconds actually tell us?

That the constraint is coordination and operational process, not ledger throughput.

Eighty seconds is far slower than a ledger can technically confirm and far faster than a conventional cross-border settlement cycle, which locates the real cost precisely: it sits in authorisation, screening, coordination between participants, and the operational steps around the transaction. That is useful information for anyone designing a platform, because it means optimising consensus mechanics is not where the time is. It also means the operational model, including who is available to act at any hour, matters more than the technology choice.

> **Is your programme optimising ledger performance or the coordination steps around the transaction?**
>
> [Talk to Digiqt about settlement platform architecture](https://digiqt.com/contact-us/)

## Where does legal finality come from?

From governing law, the rules of the arrangement, and insolvency treatment, not from the ledger.

This is the point where technology programmes most often assume too much. A state transition recorded irrevocably on a ledger is technically final, and whether it is legally final, meaning it cannot be unwound by a court or an insolvency administrator, depends on the legal framework surrounding the arrangement. The PFMI framework treats settlement finality as a matter for rules and law rather than mechanism. So the engineering deliverable includes a legal analysis: which law governs, what the rules of the arrangement say about finality and reversal, how insolvency of a participant is handled, and what happens if a token is transferred in error. Build the unwind capability the law requires rather than asserting that irreversibility is a feature.

### Why is the code settled it not sufficient?

Because participants need certainty enforceable outside the platform.

If a transfer occurred through operational error, fraud, or a defect, someone will seek redress, and the platform's rules must say how that is handled. Designs that treat immutability as absolute end up with either no remedy or an ad hoc one improvised under pressure, and neither is acceptable in a regulated settlement context. Define the correction mechanism, restrict who can invoke it, log it comprehensively, and make it rare by design rather than impossible. The audit trail patterns that support this are the ones in [event sourcing and audit trails](https://digiqt.com/blog/event-driven-trading-system-architecture/).

## How do you handle failure modes?

With explicit timeouts, a defined unwind path, and an operational process for the aftermath.

| Failure | Consequence | Required design |
|---|---|---|
| One leg unavailable at settlement | Neither leg should settle | Conditional execution, no partial state |
| Timeout expiry in a cross-ledger protocol | Unwind with locked assets released | Defined timeout, monitoring, re-execution path |
| Participant system unavailable | Settlement cannot complete | Queuing, retry, deadline management |
| Smart contract defect | Potential incorrect state | Upgrade path, pause capability, formal review |
| Key loss or compromise | Assets unreachable or at risk | Key management, recovery arrangements, revocation |
| Ledger fork or reorganisation | Ambiguous state | Finality rules, permissioned design choices |
| Erroneous transfer | Wrong party holds an asset | Rules-based correction with governance |

The operational aftermath deserves as much attention as the technical unwind. A trade that failed to settle leaves participants with market exposure they expected to close, so the platform needs to notify quickly, state the position clearly, and support re-execution, which is the same discipline required when a payment fails on an instant rail as described in [FedNow and RTP participation](https://digiqt.com/blog/fednow-rtp-integration/).

## How does it interoperate with existing infrastructure?

Through standard messaging and deliberate bridges, because replacement is not on the table.

Agorá's testing specifically demonstrated interoperability with existing RTGS and core banking systems using ISO 20022, which is the right model: the tokenised platform participates in the existing ecosystem rather than expecting it to migrate. Practically that means mapping to and from standard messages, reconciling ledger state against depositary and core banking records continuously, and accepting that operating hours differ between the platform and the systems it connects to. Consistent structured data is what makes the mapping viable, which is why the CPMI's harmonised ISO 20022 data requirements matter here as much as in payments. Multi-party platform governance brings its own considerations, as covered in [multi-party data sharing and consortium models](https://digiqt.com/blog/federated-fraud-data-sharing/).

## What operational model does continuous settlement need?

Coverage, liquidity, and change management for a platform that does not close.

A settlement platform available continuously creates the same obligations as an instant payment rail: someone must be available to act at any hour, liquidity must be positioned without a funding window, and changes must be deployable under live traffic. Those requirements are frequently discovered late in tokenisation programmes because the pilot ran during business hours. Plan the operating model alongside the architecture, and note that clearing and collateral processes connected to the platform inherit the same constraints, as discussed in [CCP clearing connectivity architecture](https://digiqt.com/blog/ccp-clearing-connectivity-architecture/).

## How should a programme be sequenced?

Legal and cash leg first, then a narrow asset class, then interoperability, then scale.

| Phase | Duration | Deliverable |
|---|---|---|
| Legal and finality analysis | 2 to 4 months | Governing law, rules, insolvency treatment, correction mechanism |
| Cash leg decision | 2 to 3 months | Selected instrument with treasury, risk, and legal sign-off |
| Narrow asset class pilot | 4 to 6 months | One instrument type, one settlement pattern, real participants |
| Failure path engineering | 2 to 3 months | Timeouts, unwind, notification, re-execution, rehearsed |
| Interoperability | 3 to 5 months | ISO 20022 mapping, reconciliation to depositary and core |
| Operating model for continuous settlement | 2 to 3 months | Coverage, liquidity, live change capability |
| Scale and additional asset classes | Ongoing | Incremental, with reconciliation maintained throughout |

Legal analysis first is not caution, it is the requirement that determines the architecture. A design that cannot be unwound in the circumstances the law requires will not be approved, and discovering that after the platform is built is the most expensive possible sequencing. The honest framing about where distributed ledger technology genuinely helps and where it does not is set out in this assessment of blockchain use cases versus hype.

## Which metrics matter?

Settlement success rate, time to settlement, failed leg incidence, unwind execution, and reconciliation breaks.

Report settlement success rate and, separately, the incidence of failures where one leg was ready and the other was not, since that distinguishes counterparty readiness from platform capability. Track time from instruction to final settlement at the median and the tail. Measure unwind executions and their operational aftermath, including time to re-execute. Report reconciliation breaks against depositary, core banking, and participant records, which is where a tokenised platform quietly diverges from the rest of the estate. And track availability across the full calendar rather than business hours, because continuous settlement is the property being claimed.

Atomic settlement on distributed ledgers is now demonstrably feasible, and the evidence suggests the hard parts are exactly where they always were: the cash leg, the legal framework, and what happens when something fails. Programmes that treat those three as the deliverable and the ledger as an implementation detail are the ones likely to reach production.

## Frequently Asked Questions

### What problem does atomic settlement solve?

Principal risk, meaning the risk that one party delivers and the other does not. Atomicity makes both legs conditional on each other so neither completes alone.

### Is delivery-versus-payment new?

No. Existing infrastructures already deliver DvP through central securities depositories and settlement systems. Tokenisation changes the mechanism and the timing, not the objective.

### What is the hardest design decision?

The cash leg. Whether you settle against tokenised central bank money, tokenised deposits, a stablecoin, or an off-ledger payment determines your legal and operational model.

### Why is single-ledger settlement simplest?

Because both legs move in one transaction with no coordination protocol. It is also hardest to achieve, since it requires cash and securities on the same platform.

### Does technical settlement give legal finality?

Not by itself. Finality depends on governing law, the rules of the arrangement, and insolvency treatment, so the legal analysis has to accompany the engineering.

### What has live experimentation shown?

That multi-currency atomic settlement using tokenised reserves and deposits is feasible. BIS Project Agora's July 2026 real-value test settled in around 80 seconds on average.

### What happens when one leg fails?

Nothing should settle. The design needs explicit timeouts, a defined unwind path, and an operational process for participants left with positions they expected to close.

### Should this replace existing settlement infrastructure?

Not initially. Interoperability with RTGS, core banking, and existing depositories is what makes these platforms usable, and Agora tested exactly that using ISO 20022.

## Sources

- [BIS Innovation Hub, Project Agorá](https://www.bis.org/about/bisih/topics/fmis/agora.htm)
- [CPMI-IOSCO, Principles for financial market infrastructures](https://www.bis.org/cpmi/publ/d101.htm)
- [CPMI, Harmonised ISO 20022 data requirements for enhancing cross-border payments](https://www.bis.org/cpmi/publ/d230.htm)

Atomic Settlement With Delivery-Versus-Payment on Distributed Ledgers

Let Digiqt design canonical clearing models, intraday margin handling, and cross-venue collateral for multi-market participation.

One Platform, Many Clearing Houses

# Connecting to Many Clearing Houses Without Building Many Platforms

Firms rarely set out to build a separate clearing platform per venue. It happens incrementally: the first CCP connection is built for that CCP's formats and timings, the second arrives with a different margin methodology and a different collateral schedule under a delivery deadline, and by the fourth there are four codebases, four reconciliation processes, and four operations teams who each know one venue.

The cost of that estate is not the build. It is that every regulatory change, every new market, and every intraday incident has to be handled four times, and no single view of margin or collateral exists across them. Getting CCP clearing connectivity architecture right means deciding early what is genuinely common and confining the rest to adapters.

## What does clearing connectivity actually involve?

More than trade submission: position lifecycle, margin, collateral, settlement, reporting, and default arrangements.

| Function | What the platform must handle |
|---|---|
| Trade submission and acceptance | Formats, validation, rejection handling, give-up and allocation |
| Position management | Netting, compression, lifecycle events, expiry and exercise |
| Margin | Initial and variation margin, intraday calls, methodology differences |
| Collateral | Eligibility, haircuts, substitution, concentration limits per venue |
| Settlement and cash | Payment obligations in multiple currencies to deadlines |
| Reporting | Position, margin, and transaction reporting obligations |
| Default arrangements | Default fund contributions, stress calls, porting readiness |
| Corporate and contract events | Expiries, deliveries, adjustments per product |

### Which access model are you operating?

Direct membership, client clearing through a broker, or sponsored access, and the difference is substantial.

| Model | Obligations | Operational load | Suits |
|---|---|---|---|
| Direct clearing member | Full membership including default fund and stress calls | Highest | Scale participants with capital and operations |
| Client clearing via a clearing broker | Contractual with the broker, broker faces the CCP | Moderate | Most participants |
| Sponsored or direct client access | Direct CCP relationship with sponsor support | Moderate to high | Participants seeking capital efficiency |
| Mixed across venues | Different models per market | Highest complexity | Common in practice, needs one internal model |

Most firms end up mixed, which is exactly why the internal model must be canonical. If your platform's data model reflects one access model, the second one arrives as a parallel implementation.

> **Does your platform model positions and margin the same way across every venue and access model?**
>
> [Talk to Digiqt about a clearing connectivity architecture review](https://digiqt.com/contact-us/)

## How do you build a canonical model across CCPs?

By separating what is economically common from what is venue-specific, then holding the specifics in adapters.

Common across venues: the concept of a cleared position with a product, quantity, and counterparty facing a CCP; an exposure requiring margin; a collateral obligation and the assets meeting it; a cash payment obligation with a currency and deadline; and a lifecycle of events changing any of those. Venue-specific: margin methodology and its inputs, call schedules and deadlines, message formats and identifiers, collateral eligibility and haircuts, reporting content, netting and compression rules, and default arrangements.

### Why adapters rather than forks?

Because a fork per venue multiplies every future change by the number of venues.

Hold one internal representation and let each adapter translate: submit in the venue's format, interpret its margin call, map its collateral schedule, and normalise its reports into your model. Then a regulatory change touches one place plus the affected adapters, a new market is an adapter rather than a programme, and cross-venue reporting becomes a query rather than a consolidation exercise. This is the same reasoning that governs payment rail adapters, and the failure mode is identical: an internal model shaped by the first integration cannot accommodate the second cleanly.

## How do margin processes shape the architecture?

Through intraday calls, which impose minutes-scale response requirements on everything they touch.

Initial margin covers potential future exposure and changes with positions and methodology parameters. Variation margin settles mark-to-market daily or more frequently. Intraday calls arrive when markets move or exposures grow, with same-day deadlines measured in hours. That last category is what determines your architecture: to meet a call you need the current position, the exposure calculation, available collateral, an allocation decision, and an instruction, within a window that leaves no room for an overnight process. Design the whole chain for that path and the daily cycle is a special case rather than the primary design.

### What is the operational deadline problem?

Deadlines are set by venues in their local time zones and do not coordinate with each other.

A firm clearing across regions faces calls with deadlines in several time zones, sometimes overlapping, sometimes at hours when the relevant team is not working. Map every deadline explicitly, model the follow-the-sun coverage required, and automate collateral instruction generation so meeting a call does not depend on a specific person being awake. Then rehearse the compressed scenario: several venues calling simultaneously during a stressed market, which is precisely when the calls correlate. Intraday visibility of positions and cash is the dependency, which connects to [intraday liquidity monitoring](https://digiqt.com/blog/intraday-liquidity-monitoring/).

## How do you manage collateral across venues?

Centrally, because per-venue optimisation leaves value on the table.

Each CCP has its own eligibility schedule, haircuts, and concentration limits, and a firm holding one asset pool faces a joint allocation problem rather than several independent ones. Optimising venue by venue posts high-quality liquid assets where cheaper collateral would have been accepted, because the local decision cannot see the alternative use. Model the pool once, apply per-venue constraints from the adapters, and allocate across all obligations together, including bilateral and securities financing obligations where possible. The optimisation mechanics and the discipline of machine-readable eligibility are covered in [securities lending and repo platform design](https://digiqt.com/blog/securities-lending-repo-platform/).

> **Are you optimising collateral per clearing venue or across the whole obligation set?**
>
> [Talk to Digiqt about cross-venue collateral allocation](https://digiqt.com/contact-us/)

## What reconciliation is required?

Trade, position, margin, collateral, and cash against every venue, daily and intraday where calls occur.

| Reconciliation | Frequency | Why it matters |
|---|---|---|
| Trade level | Continuous or intraday | Submission failures and rejections caught early |
| Position | Daily minimum, intraday preferred | Position breaks become margin and settlement errors |
| Margin requirement | Every call | A disputed calculation needs your own number to argue from |
| Collateral holdings | Daily | What the venue holds versus what you believe you posted |
| Cash movements | Daily | Settlement failures and interest errors |
| Reports | Per cycle | Regulatory reporting accuracy depends on it |

Position breaks are the ones that escalate fastest, because a position difference produces a margin difference which produces a call you did not expect. Reconcile positions with enough frequency that a break is found before it is priced, and be able to recompute your own margin number independently, since a firm that cannot reproduce a calculation cannot dispute it. The reporting discipline resembles this guide to [audit-ready reporting](https://digiqt.com/blog/audit-ready-ci-cd-financial/).

## What about resilience, default, and porting?

Design for venue outage, member default, and the operational reality of moving client positions.

CCPs are systemically important infrastructures and the CPMI-IOSCO Principles for financial market infrastructures, published in April 2012, apply to central counterparties alongside payment systems, central securities depositories, securities settlement systems, and trade repositories, raising minimum requirements and broadening risk-management coverage. CPMI-IOSCO's June 2016 guidance on cyber resilience for FMIs adds the expectation that infrastructures anticipate threats, respond rapidly, and achieve faster and safer target recovery objectives. For a participant, three practical requirements follow. First, plan for a venue being unavailable, including what happens to obligations and positions during it. Second, understand your exposure to a fellow member's default, including stress call obligations if you are a direct member. Third, make porting operationally real: transferring client positions and collateral to another clearing member under time pressure requires tested data extraction, agreed formats, and rehearsed process rather than a contractual clause. Include clearing access in your critical business service mapping, since it is frequently a dependency of several, as described in this guide to [critical operations mapping](https://digiqt.com/blog/operational-resilience-impact-tolerance/), and the Basel Committee's Principles for operational resilience, published in March 2021, set the framing.

### Why does porting fail in practice?

Because it depends on data and process nobody has exercised.

Porting requires identifying affected client positions precisely, extracting collateral records, agreeing them with a receiving member, and executing within a window measured in days at most. Firms that have never tested it discover that client static data is inconsistent, collateral attribution is unclear, and the receiving member's format expectations differ. Rehearse it as an exercise with a counterparty, and treat the findings as the highest-priority items in your clearing roadmap, because this is the scenario where a documented plan and an executable one differ most.

## How do you handle reporting obligations?

From the transaction store, with lifecycle events captured rather than reconstructed.

Position and transaction reporting requirements vary by jurisdiction and change, so build reporting from your canonical model with venue and jurisdiction as parameters rather than writing a report generator per obligation. Capture lifecycle events as they occur, including modifications, compressions, and terminations, since reconstructing them later from end-state data is where inconsistencies enter. Retain the ability to reproduce any submission, and reconcile submitted reports against your own records rather than assuming acceptance means correctness. Cross-border participation adds settlement timing complexity, and the cut-off dynamics described in [cross-border settlement cut-off times](https://digiqt.com/blog/cross-border-payment-platform/) apply to margin and collateral movements too.

## How should delivery be sequenced?

One venue end to end on a canonical model, then adapters, then cross-venue optimisation.

| Phase | Duration | Deliverable |
|---|---|---|
| Canonical model design | 2 to 3 months | Positions, exposure, collateral, cash, lifecycle events |
| First venue end to end | 4 to 6 months | Submission, positions, margin, collateral, reconciliation |
| Intraday capability | 2 to 3 months | Minutes-scale response to calls with automated instruction |
| Second venue as adapter | 2 to 3 months | Proves the abstraction, or exposes it |
| Cross-venue collateral allocation | 3 to 4 months | Single pool, per-venue constraints, joint optimisation |
| Reporting from canonical model | 2 to 3 months | Jurisdiction-parameterised reporting with lifecycle capture |
| Resilience and porting rehearsal | 2 months | Venue outage handling, tested porting with a counterparty |

The second venue is the real test. If adding it takes as long as the first, the canonical model absorbed venue-specific assumptions and should be corrected before a third arrives, since the cost of fixing it grows with each integration. Availability requirements across regions also matter here, as covered in [multi-region failover and zero data loss](https://digiqt.com/blog/banking-multi-region-failover-rpo/).

## Which metrics matter?

Time to meet a call, margin dispute rate, position break ageing, collateral efficiency across venues, and time to add a venue.

Report time from margin call receipt to instruction sent, per venue, since that is the operational capability under stress. Track margin disputes and their resolution, which measures whether you can reproduce venue calculations. Report position breaks with ageing per venue, treating anything unresolved past a day as an escalation. Measure collateral efficiency across the whole obligation set rather than per venue, showing the value of joint allocation. Track time and cost to onboard a new venue, which is the architecture metric. And record when porting and venue-outage scenarios were last rehearsed, because those are the capabilities you will be asked about after somebody else's incident.

Multi-market clearing is a canonical-model problem with a deadline attached. Firms that build the internal representation first and treat venues as adapters can add a market in a quarter and answer a margin call in minutes. Firms that build per venue end up with a platform per relationship and no consolidated view of the collateral they are posting.

## Frequently Asked Questions

### What are the access models for clearing?

Direct clearing membership, client clearing through a clearing broker, and sponsored or direct client access models. Each changes your obligations, capital, and operational load substantially.

### Why is every CCP different in the details?

Because margin methodologies, collateral eligibility, call timing, message formats, and reporting all vary, even where the economic function is the same.

### How do you avoid building a platform per CCP?

One canonical internal model for positions, margin, and collateral, with thin adapters per venue holding the format, timing, and methodology specifics.

### Why do intraday margin calls define the architecture?

Because a call with a same-day deadline requires position, exposure, and collateral answers within minutes, which rules out any process depending on overnight batch.

### Why is optimising collateral per CCP suboptimal?

Because the same assets could serve different venues at different cost. Optimising each in isolation leaves high-quality collateral posted where cheaper assets were acceptable.

### What reconciliation is required?

Trade, position, margin, collateral, and cash, against every CCP, daily at minimum and intraday where calls occur. Position breaks are the ones that become financial quickly.

### What is porting and why does it matter?

Transferring client positions and collateral to another clearing member if one fails. It must be operationally feasible under pressure, not merely documented in a contract.

### What standards frame CCP expectations?

The CPMI-IOSCO Principles for financial market infrastructures cover central counterparties among other systemically important infrastructures, including risk management expectations.

## Sources

- [CPMI-IOSCO, Principles for financial market infrastructures](https://www.bis.org/cpmi/publ/d101.htm)
- [CPMI-IOSCO, Guidance on cyber resilience for financial market infrastructures](https://www.bis.org/cpmi/publ/d146.htm)
- [BCBS, Principles for operational resilience](https://www.bis.org/bcbs/publ/d516.htm)

CCP Clearing Connectivity Architecture for Multiple Markets

Let Digiqt design golden record construction, entitlement calculation, and deadline control for corporate actions.

Automate The Events, Protect The Entitlements

# Turning Announcements Into Entitlements Without Losing Money in the Middle

Corporate actions processing is the part of post-trade that resisted automation longest, and the reason is not technical conservatism. An announcement arrives as prose, sometimes in a language other than the one your operations team reads, from several sources that do not agree on the ratio or the dates. Rules differ by market. Many events require a client decision before a deadline set by an intermediary who set it earlier than the market's own. And a mistake at any point is a direct financial loss to a client rather than a processing delay.

That combination is why corporate actions automation pays disproportionately. The manual effort is high, the error cost is direct, and a meaningful share of the losses are quietly absorbed as operational cost rather than reported as anything.

## What makes this genuinely hard?

Unstructured announcements, disagreeing sources, market-specific rules, client decisions against deadlines, and long intermediary chains.

| Difficulty | Consequence |
|---|---|
| Announcements arrive as text with varying formats | Manual interpretation and re-keying |
| Multiple data sources disagree on terms | Wrong terms propagate into entitlements |
| Market practice differs by jurisdiction | One rule set cannot serve a global book |
| Events require client elections with deadlines | Time pressure and default risk |
| Long chains of intermediaries | Each hop adds an earlier deadline and a re-keying risk |
| Amendments and cancellations arrive late | Recalculation after notification has gone out |
| Tax treatment varies by holder and market | Documentation-driven, not computable alone |
| Fractional entitlements | Rounding decisions with client impact |

### Where do the losses actually occur?

Missed deadlines, incorrect entitlements, unclaimed compensation, and unreclaimed tax.

Those four categories account for most of the financial damage, and only the first is usually visible as an incident. Incorrect entitlements get discovered on reconciliation, market claims go unpursued because nobody owns them, and withholding tax reclaim is left because the documentation effort exceeds the perceived benefit per event. Quantify all four before designing a programme, because the business case is frequently much stronger than the manual effort saving alone suggests.

> **Do you know the annual value of unreclaimed tax and unpursued market claims across your book?**
>
> [Talk to Digiqt about a corporate actions loss assessment](https://digiqt.com/contact-us/)

## What does the processing chain look like?

Ten stages, with automation potential varying sharply between them.

| Stage | Purpose | Automation potential |
|---|---|---|
| Announcement capture | Ingest from depositaries, vendors, issuers, agents | High, with extraction |
| Scrubbing and golden record | Reconcile sources into one authoritative event | High, with exception workflow |
| Eligibility determination | Which holdings are affected | High |
| Entitlement calculation | What each holder receives | High, if positions are right |
| Client notification | Inform holders with terms and deadlines | High |
| Election capture | Collect client instructions | High, with assisted exceptions |
| Instruction to market | Submit elections upstream | High, with messaging |
| Settlement and posting | Receive and allocate proceeds | High |
| Reconciliation | Confirm expected against actual | High |
| Market claims and compensation | Pursue and settle differences | Moderate, needs ownership |

The bottleneck is almost never the calculation. It is scrubbing, election chasing, and claims, which is where the people are and where the automation should be aimed first.

## How do you build the golden record?

By comparing multiple sources, applying documented precedence, and routing discrepancies to a human.

Take feeds from the depositary, one or more commercial data vendors, and where available the issuer or agent, then compare field by field: event type, key dates, ratios, prices, options available, and conditions. Where they agree, proceed automatically. Where they disagree, apply documented precedence rules and route material differences for review, since a difference in a ratio is a client loss waiting to happen. Version every event so an amendment produces a new version rather than an overwrite, and keep the full history, because you will need to explain what you believed on the day you notified clients. The document extraction that makes capture tractable is covered in this guide to [financial document intelligence pipelines](https://digiqt.com/blog/financial-document-intelligence-pipeline/).

### Why is a single source insufficient?

Because sources disagree often enough to matter, and the error becomes yours once you act on it.

Depositary announcements can be incomplete or late, vendor data can contain transcription errors, and issuer communications can be superseded. A single-source process inherits every error without any chance of detection, and the loss lands on your client. Multi-source comparison is the control, and the exception rate it produces is a useful data quality measure on your providers rather than an inconvenience.

### How should amendments be handled?

As a new event version with mandatory reassessment of everything already sent.

Amendments arrive after notifications have gone out and sometimes after elections have been received, so the workflow must recalculate entitlements, identify affected clients, decide whether elections remain valid, re-notify with the change made explicit, and reopen the election window where the market permits. Automate the detection and the impact assessment, and keep a human decision on client communication, since the message matters. Record the whole sequence, because an amended event handled badly generates complaints and sometimes claims.

## How do you calculate entitlements correctly?

From positions as at the correct record date, including lending, borrowing, and unsettled trades.

### Why are securities on loan the classic error?

Because economic entitlement and registered holding diverge, and the calculation must follow the contract.

A holding lent out is not in the account on record date, and the borrower may receive the distribution, with the lender's entitlement handled through a manufactured payment under the lending agreement. Ignore that and you either double-count or under-pay. The same applies to pending settlements around record date, repo positions, and collateral pledged away. The entitlement engine therefore needs a complete economic position view rather than a custody position, and that view has to come from the lending and financing systems, which is the integration described in [securities lending and repo platform design](https://digiqt.com/blog/securities-lending-repo-platform/). Reconciling pledged and lent positions against records is the same discipline as in this guide to [pledged asset reconciliation](https://digiqt.com/blog/nostro-vostro-reconciliation-automation/).

### Why must rounding policy be explicit?

Because fractional entitlements arise constantly and different treatments produce different client outcomes.

A one-for-seven bonus issue on an odd holding produces a fraction, and the treatment, rounding down with cash for the remainder, rounding to nearest, or aggregating across clients, changes what each client receives. Document the policy per event type and market, apply it consistently, and disclose it, because an undocumented default becomes an unexplainable difference during a client query. Aggregation across clients in particular needs a clear position, since any benefit arising from aggregation belongs to someone and that question is better answered in advance.

## How should elections and deadlines be managed?

With an internal deadline earlier than the market's, a documented default, escalation, and recorded evidence.

Set your client-facing deadline early enough to instruct upstream comfortably, and be explicit that it is your deadline rather than the market's. Define the default action for non-response per event type, communicate it clearly at notification, escalate as the deadline approaches through channels the client actually monitors, and record every notification, reminder, and response with timestamps. When a client misses a deadline and disputes it, that record is the entire basis of your position, and it needs to show what was sent, when, to whom, and what the stated default was. Standing instructions help for repetitive event types and need periodic re-confirmation rather than indefinite persistence.

> **If a client disputed a missed election, could you produce every notification with timestamps?**
>
> [Talk to Digiqt about election workflow and evidence design](https://digiqt.com/contact-us/)

## How does message standardisation help?

By removing manual interpretation and re-keying between intermediaries.

Structured messaging is what allows an event to pass along a chain without being retyped, and inconsistent implementation is what undermines it. The CPMI's harmonised ISO 20022 data requirements exist because participants implement the same standard differently, and the same lesson applies here: a technically valid message populated inconsistently still requires human interpretation. Adopt the standard properly, populate the fields the same way every time, and treat any re-keying between systems in your own chain as a defect to remove. The data exchange problem across counterparties is well described in this guide to [slow data exchange between parties](https://digiqt.com/blog/federated-fraud-data-sharing/), and asset-level allocation exchange in Modco asset allocation automation.

## How do you handle market claims and tax?

As owned workflows with thresholds, not as residual activity.

Market claims arise when entitlement and settlement diverge around record date, and they need a process that detects the difference, values it, raises the claim within market timeframes, and pursues it. Without ownership they simply do not get raised, which is a pure loss. Withholding tax is harder, because entitlement to a treaty rate depends on beneficial ownership, documentation, and market-specific procedures, making reclaim a documentation workflow rather than a calculation. Automate the detection and the case creation, track documentation validity and expiry per client and market, and set a threshold below which pursuit is uneconomic so the decision is deliberate rather than accidental.

## How should automation be sequenced?

Capture and scrubbing first, then entitlements, then elections, then claims and tax.

| Phase | Duration | Deliverable |
|---|---|---|
| Multi-source capture and extraction | 3 to 5 months | Automated ingestion with structured extraction |
| Golden record and scrubbing | 3 to 4 months | Comparison, precedence, versioning, exception workflow |
| Economic position integration | 2 to 4 months | Lending, repo, pending settlement included |
| Entitlement engine | 3 to 4 months | Calculation with explicit rounding policy per market |
| Notification and election capture | 3 to 4 months | Structured notification, digital election, evidence trail |
| Upstream instruction messaging | 2 to 3 months | Standard messages, no re-keying |
| Reconciliation and claims | 2 to 3 months | Automated detection, owned pursuit, thresholds |
| Tax reclaim workflow | 3 to 5 months | Documentation tracking, case management, thresholds |

Scrubbing before entitlements is deliberate: a perfectly engineered entitlement calculation on wrong event terms produces confident wrong numbers, which is worse than a manual process that hesitates. The reconciliation mechanics resemble those in [nostro and vostro reconciliation automation](https://digiqt.com/blog/nostro-vostro-reconciliation-automation/), and the settlement infrastructure context sits within the CPMI-IOSCO Principles for financial market infrastructures, published in April 2012, which cover central securities depositories and securities settlement systems among other systemically important infrastructures.

## Which metrics matter?

Straight-through rate by event type, scrubbing exception rate by source, missed deadlines, entitlement corrections, claims pursued, and tax reclaimed.

Report straight-through processing rate by event type rather than in aggregate, since mandatory cash distributions and complex voluntary events are different problems. Track scrubbing exceptions by source, which doubles as a data quality scorecard on your providers. Count missed election deadlines with cause, treating each as an incident. Report entitlement corrections after notification, because those are client-visible errors. Measure market claims raised versus identified, and tax reclaimed versus reclaimable, since both gaps are recoverable money. And track manual touches per event, which is the operating cost the programme exists to reduce.

Corporate actions is the clearest remaining example in post-trade of a process where manual effort and financial loss travel together. The automation that works starts by trusting no single announcement source, insists on an economic position view that includes lent and pledged securities, and treats election evidence and unclaimed money as first-class rather than residual.

## Frequently Asked Questions

### Why is corporate actions the least automated part of post-trade?

Because announcements arrive unstructured from multiple sources that disagree, market rules differ, and many events require a client decision against a deadline.

### Where do the losses actually occur?

Missed election deadlines, incorrect entitlement calculations, unclaimed market claims, and unreclaimed withholding tax. Most are operational rather than market losses.

### Why is trusting a single announcement source insufficient?

Because sources disagree on terms, dates, and ratios, and an error propagated into entitlements becomes a client loss. Comparison across sources is the control.

### What is the most common entitlement calculation error?

Ignoring securities on loan or pending settlement. Positions must be evaluated as at the correct record date including lending, borrowing, and unsettled trades.

### Why must rounding policy be explicit?

Because fractional entitlements arise constantly and different treatments produce different client outcomes. An undocumented default becomes an unexplainable discrepancy.

### How should election deadlines be managed?

With an internal deadline earlier than the market deadline, a documented default action, escalation before expiry, and recorded evidence of what the client was told and when.

### How does message standardisation help?

Structured, harmonised messaging reduces manual interpretation and re-keying between intermediaries, which is where most errors and delays are introduced.

### What makes tax the hardest part?

Entitlement to treaty rates depends on documentation, beneficial ownership, and market-specific procedures, so reclaim is a documentation workflow rather than a calculation.

## Sources

- [CPMI-IOSCO, Principles for financial market infrastructures](https://www.bis.org/cpmi/publ/d101.htm)
- [CPMI, Harmonised ISO 20022 data requirements for enhancing cross-border payments](https://www.bis.org/cpmi/publ/d230.htm)

Corporate Actions Automation for Global Custody Operations

Let Digiqt design control models, paper fallback, and interoperability for digital trade documents.

Electronic Documents That Actually Transfer

# Making an Electronic Bill of Lading Work as a Document of Title

Trade finance digitisation has been attempted repeatedly and stalled for the same reason each time. Scanning a bill of lading produces an image, not a document of title. The paper works because possession of the original confers rights, and an electronic copy that can be duplicated confers nothing. Until the legal framework recognised an electronic equivalent, the industry could digitise the workflow around the document and not the document itself.

That is what changed. The UNCITRAL Model Law on Electronic Transferable Records, adopted on 13 July 2017, provides the legal basis, and building digital trade documents MLETR frameworks support is now an engineering problem with three specific requirements rather than a legal impossibility.

## What does MLETR actually change?

It establishes functional equivalence, replaces possession with control, and requires a reliable method.

| Requirement | What it means |
|---|---|
| Functional equivalence | The electronic record contains the information the transferable document requires, and uses reliable methods for identification, capability of control, and maintaining integrity |
| Control replacing possession | Possession requirements are satisfied when a reliable method establishes exclusive control of the record by a person, and identifies that person as the one in control |
| Reliable method | The law uses this standard throughout and delegates the specific assessment of reliability to implementing States |
| Technology neutrality | The framework accommodates registries, tokens, and distributed ledgers, with non-discrimination between technologies |

### Why does the reliability standard being delegated matter?

Because the bar your system must meet is set by the implementing jurisdiction, not by the model law.

The model law states the requirement and leaves States to determine how reliability is assessed, with the accompanying explanatory note providing guidance. In practice that means your platform's design must satisfy whichever jurisdictions govern the transactions you support, and those assessments can differ. Get the legal analysis per relevant jurisdiction before committing to an architecture, since a control mechanism accepted in one market may not clear the bar in another, and retrofitting is expensive.

> **Have you established which jurisdictions' reliability standards your platform must satisfy?**
>
> [Talk to Digiqt about control model design and legal alignment](https://digiqt.com/contact-us/)

## Which documents matter, and which is hardest?

Several transferable documents qualify, and the bill of lading is the demanding case.

| Document | Function | Difficulty |
|---|---|---|
| Bill of lading | Receipt, contract of carriage, and document of title | Highest, because title transfers |
| Warehouse receipt | Evidence of goods held, sometimes negotiable | High |
| Promissory note | Payment undertaking, transferable | Moderate to high |
| Bill of exchange | Transferable payment instruction | Moderate to high |
| Letter of credit and presented documents | Payment undertaking against compliant presentation | Moderate, workflow heavy |
| Certificates and invoices | Supporting evidence, not transferable | Low, ordinary document handling |

The bill of lading is hard because it does three jobs at once and because the third one, document of title, means whoever controls it can claim the goods. That is why singularity of control matters far more here than for a certificate of origin, where a duplicate is merely untidy.

## What does exclusive control require technically?

Singularity, controlled transfer, integrity, and identification of the controller.

Singularity means one controllable record exists rather than copies that each appear authoritative. Transfer means control can move from one identified party to another with the previous holder losing it in the same operation. Integrity means the record cannot be altered without detection. Identification means the system can state who holds control at any moment and evidence it. Those four properties are what a reliability assessment will examine, and each needs to be demonstrable rather than asserted.

### Why is singularity the core property?

Because a duplicable document of title defeats the entire model.

If two parties can each present a record and each appear to control it, the carrier cannot know who to release goods to, financiers cannot know what they hold security over, and the electronic document is worse than paper because paper at least cannot be copied convincingly. Whatever the underlying technology, the system must guarantee that control exists in exactly one place, that transfer is atomic, and that the previous holder cannot continue to act as controller.

### Registry, token, or ledger?

All three are permitted, and the choice should follow governance rather than technology preference.

| Model | Control mechanism | Strengths | Considerations |
|---|---|---|---|
| Central registry | Registry records the controller | Simple, clear governance, easy to evidence | Registry operator is a critical dependency |
| Token on a permissioned ledger | Holding the token confers control | Transferable between participants, auditable | Governance of the network, key custody |
| Token on a public ledger | Cryptographic control | Wide reach | Legal comfort, privacy, key loss consequences |
| Interoperating platforms | Control transfers between systems | Reach without one dominant operator | Handover protocol is the hard part |

The model law's technology neutrality is genuinely useful here, because it means the decision can be made on governance, counterparty reach, and legal comfort. Multi-party platform governance is itself a substantial question, as discussed in [multi-party data sharing and consortium models](https://digiqt.com/blog/federated-fraud-data-sharing/).

## How do you handle the legal patchwork?

By designing for uneven adoption, including reversion to paper.

Adoption of the model law is progressing rather than complete, and a single shipment may involve a shipper, a carrier, a consignee, banks, and a port authority across jurisdictions with different positions. Handle it explicitly: record which law governs each instrument, check counterparty and jurisdiction readiness before issuing electronically, and support conversion to paper where a party or authority requires it.

### Why must paper fallback be designed rather than improvised?

Because converting mid-transaction has legal consequences that need a defined process.

If an electronic record must become paper, the electronic version must cease to be operative at the moment the paper is issued, with evidence of that switch, or you have created two documents purporting to confer the same rights. Design the conversion as a controlled operation with the record marked as converted, the paper issued with reference to it, and the whole sequence auditable. Improvising this at a port when an authority refuses an electronic presentation is how a digitisation programme creates a title dispute. The wider problem of documentation that must satisfy multiple jurisdictions is described in documentation at the border.

## How does this integrate with trade finance operations?

Through issuance, presentation, examination, and financing, with the mechanics changing more than the judgment.

For a letter of credit, digitisation changes how documents are presented and checked rather than what the credit requires. Structured data allows automated verification of many conditions such as dates, amounts, quantities, and party names, which removes a large amount of manual comparison. What it does not remove is the examiner's judgment about whether a presentation complies, particularly where documents are inconsistent in ways rules address specifically. So the target is a system that automates the checkable and presents the examiner with the exceptions and the evidence, which is the same pattern as document intelligence generally, as described in [financial document intelligence pipelines](https://digiqt.com/blog/financial-document-intelligence-pipeline/).

### What changes for guarantees and undertakings?

Less than for documents of title, because those instruments already work as undertakings rather than through possession.

Independent guarantees and standby letters of credit operate as undertakings to pay against a compliant demand, and the UNCITRAL Convention on Independent Guarantees and Stand-by Letters of Credit, adopted in December 1995 and in force since January 2000, established common principles across those instruments. Digitising them is mostly about structured issuance, amendment, and demand handling rather than about control and singularity, which is why they are frequently the easier starting point. The lifecycle platform for those instruments is covered in [bank guarantee management system design](https://digiqt.com/blog/bank-guarantee-management-system/).

> **Does your trade platform automate the checkable conditions and escalate only genuine discrepancies?**
>
> [Talk to Digiqt about document examination automation](https://digiqt.com/contact-us/)

## How do you handle interoperability between platforms?

By treating the handover between systems as a first-class protocol rather than an integration afterthought.

Several platforms exist and no single one has universal reach, so a record will need to move between systems while preserving singularity and evidence of control. That handover is the hard problem: the originating system must relinquish control atomically, the receiving system must accept it, and the audit trail must span both. Insist on documented handover semantics before selecting a platform, and treat a vendor whose answer is that everyone will eventually use their network as a concentration risk. Data standard alignment matters too, since a handover that loses structured detail forces re-keying, which is the failure mode described in [slow data exchange between parties](https://digiqt.com/blog/federated-fraud-data-sharing/).

## What controls does the system need?

Party identity, key custody, audit trail, correction process, and an insolvency position.

Verify and record the identity of every party capable of holding control, because control means nothing if the controller cannot be identified. Manage credentials as the sensitive asset they are, since whoever holds them holds the document. Maintain an audit trail sufficient to evidence who controlled the record at every point, because that is what a court or an arbitrator will examine. Define a correction process for errors, with restricted authority and full logging, since a system with no remedy for a mistaken transfer is unusable in practice. And analyse insolvency: what happens to records if the platform operator fails, and whether control can be re-established elsewhere.

### Why is key management effectively possession?

Because credentials that transfer control are the practical location of title.

In a token or cryptographic model, the party holding the keys can transfer the record regardless of what any register displays, which makes key custody arrangements a legal matter rather than an operational one. Use hardware-backed custody, quorum arrangements for corporate holders, and rehearsed recovery, and be explicit with clients about what happens if their credentials are lost or compromised. The custody design is the subject of [HSM and key management architecture](https://digiqt.com/blog/hsm-key-management-financial/).

## How should adoption be sequenced?

Guarantees and undertakings first, then corridors with legal certainty, then documents of title.

| Phase | Duration | Deliverable |
|---|---|---|
| Legal analysis per jurisdiction | 2 to 4 months | Which laws govern, reliability expectations, counterparty positions |
| Structured undertakings | 3 to 4 months | Electronic issuance and amendment for guarantees and standbys |
| Document examination automation | 3 to 4 months | Automated checkable conditions, exception presentation |
| Control model implementation | 4 to 6 months | Singularity, atomic transfer, integrity, controller identification |
| Paper fallback and conversion | 2 months | Controlled conversion with evidence, rehearsed |
| Corridor pilots | 3 to 6 months | Selected trade lanes with willing counterparties and clear law |
| Interoperability | Ongoing | Handover protocols, standards alignment, concentration management |

Corridor-by-corridor adoption is the realistic path, because the constraint is counterparty and jurisdictional readiness rather than your platform. Choose lanes where the law is settled and the counterparties are willing, prove the operational model, then extend.

## Which metrics matter?

Electronic share by corridor, conversion-to-paper rate and cause, examination automation rate, transfer failures, and cycle time.

Report the electronic share of eligible instruments per corridor, since that reveals where adoption is real. Track conversions to paper with the reason, because those reasons tell you which jurisdictions and counterparties to work on. Measure the share of examination conditions checked automatically and the discrepancy rate that still needs judgment. Count control transfer failures and their causes, targeting zero, since a failed transfer in this context is a title problem. And measure end-to-end cycle time against the paper baseline, which is the benefit the business case rests on and is frequently the most persuasive number available.

Trade document digitisation finally has a legal foundation, which moves the difficulty from whether it is possible to whether your control mechanism is reliable, your fallback is designed, and your counterparties are ready. Those three are solvable one trade lane at a time, which is considerably better than the position the industry occupied for the previous two decades.

## Frequently Asked Questions

### What does MLETR actually change?

It provides a legal basis for electronic equivalents of transferable documents, replacing possession with control and requiring a reliable method for identification, control, and integrity.

### What is functional equivalence?

An electronic record qualifies when it contains the information the paper document requires and uses reliable methods for identification, capability of control, and maintaining integrity.

### Why is control the central concept?

Because paper documents of title work through possession, and the electronic equivalent requires a reliable method establishing exclusive control by an identified person.

### Why is singularity the hard technical property?

Because a document of title must exist as one controllable thing. A record that can be duplicated so two parties both appear to control it defeats the entire model.

### Which design should you use: registry, token, or ledger?

The model law is technology neutral and accommodates all three. The choice should follow governance, counterparty reach, and legal comfort rather than technical preference.

### Why must paper fallback be designed?

Because adoption is uneven across jurisdictions and counterparties, so a transaction may need to revert to paper mid-flow, and improvising that under time pressure creates legal risk.

### What changes for document examination?

The mechanics rather than the judgment. Structured data enables automated checking of many conditions, and the examiner still decides whether a presentation complies.

### Why is key management effectively possession?

Because whoever controls the credentials controls the record, so key custody arrangements are the practical location of title regardless of what a register displays.

## Sources

- [UNCITRAL Model Law on Electronic Transferable Records (2017)](https://uncitral.un.org/en/texts/ecommerce/modellaw/electronic_transferable_records)
- [UNCITRAL, United Nations Convention on Independent Guarantees and Stand-by Letters of Credit](https://uncitral.un.org/en/texts/payments/conventions/independent_guarantees)

Digitizing Letters of Credit and Trade Documents Under MLETR

Let Digiqt design normalisation, instrument mapping, and reconciliation for consolidated custody data.

One View Across The Whole Network

# One View of Assets Held by Forty Different Agents

A global custodian holds nothing directly in most markets. Assets sit with sub-custodians, each reporting in their own rhythm, each populating message standards their own way, each using local identifiers and local conventions about what a position means before settlement completes. The client, meanwhile, wants one statement showing what they own, in their reporting currency, as at a stated moment.

Global custody data consolidation is the work between those two facts. It is rarely a messaging project, because the messages usually arrive fine. It is a normalisation and reconciliation project where instrument identity and timing do most of the damage.

## Why is consolidation hard when everyone uses standards?

Because a standard message can be technically valid and semantically inconsistent.

| Variation | Example |
|---|---|
| Field population practice | The same standard field used for different purposes by different agents |
| Instrument identifiers | Local codes, international identifiers, and internal codes all in play |
| Position semantics | Traded, settled, and available positions defined differently |
| Reporting timing | Local cut-offs across time zones, with no common as-at |
| Corporate action detail | Varying completeness and terminology |
| Tax and fee reporting | Market-specific treatment and inconsistent breakdown |
| Settlement conventions | Different cycles and finality timing per market |
| Account hierarchy | Omnibus, segregated, and nominee structures represented differently |

The CPMI's work on financial messaging makes the general point plainly: legacy formats truncate data, translation between standards loses information, and harmonised data requirements exist precisely because participants implement the same standard differently. In custody that shows up as forty agents whose messages parse cleanly and mean subtly different things.

### Why is instrument identity the root problem?

Because every position and transaction depends on knowing which security it refers to.

The same instrument may arrive identified by a local market code from one agent, an international identifier from another, and an internal code from your own systems, with corporate actions changing identifiers over time and some instruments carrying several valid codes simultaneously. Build an instrument master with a mapping layer, treat identifier resolution failures as blocking exceptions rather than warnings, and version the mapping so historical positions remain interpretable. Institutions that treat this as reference data plumbing discover it is the dependency for every downstream number.

> **Do identifier resolution failures block a position from consolidating, or pass through as warnings?**
>
> [Talk to Digiqt about instrument mastering and normalisation](https://digiqt.com/contact-us/)

## What has to be consolidated?

Eight data domains, with the later ones considerably harder than the first.

| Domain | Difficulty | Why |
|---|---|---|
| Positions | Moderate | Semantics of settled, traded, and available differ |
| Transactions | Moderate | Lifecycle states and cancellation handling vary |
| Cash balances and movements | Moderate | Multi-currency, value dating, interest treatment |
| Corporate actions | High | Announcement detail, entitlement, election status |
| Income and distributions | High | Timing, gross versus net, currency conversion |
| Tax | High | Withholding, reclaim status, documentation dependency |
| Fees and charges | Moderate to high | Inconsistent breakdown, market-specific components |
| Encumbrance and availability | High | Lending, pledging, restrictions rarely reported uniformly |

Encumbrance is the one most often omitted from consolidation programmes and the one that most affects decisions, because a consolidated position that does not distinguish held from available will be used to make an availability decision and will be wrong. That connects directly to the inventory problem in [securities lending and repo platform design](https://digiqt.com/blog/securities-lending-repo-platform/).

## How do you build the consolidated record?

By normalising to a canonical model with explicit as-at timing and full provenance.

Define one internal representation of a position, a transaction, a cash balance, and an entitlement, then translate each agent's reporting into it through an adapter that holds that agent's conventions. Keep the raw message alongside the normalised record, since investigation always needs the original. Record for every value which agent reported it, when they reported it, and as at what moment, because those three attributes are what let you explain a number to a client or an auditor. The mapping of local practice to canonical meaning is the intellectual property of the platform and it needs an owner rather than being distributed across adapters.

### Why must as-at timing be explicit?

Because agents report at different local cut-offs and a consolidated position without a stated moment mixes them.

If one agent reports as at their close and another as at yours, the consolidated total describes no single moment in time. State the as-at explicitly, hold positions with both the reported time and the effective time, and support querying as at any point rather than only current. That capability is also what makes reconciliation tractable, since comparing two views requires agreeing which moment you are comparing.

## How do you reconcile?

At several levels, with timing differences modelled rather than treated as breaks.

| Reconciliation | Against | Frequency |
|---|---|---|
| Internal position versus agent report | Each sub-custodian | Daily minimum |
| Three-way with depositary or market records | Where accessible | Periodic |
| Cash balances and movements | Each agent, per currency | Daily |
| Income and distributions | Expected versus received | Per event |
| Corporate action entitlements | Expected versus credited | Per event |
| Encumbrance | Lending and collateral systems | Daily |

### What tolerance and ageing policy applies?

Zero tolerance on quantity and value, with timing differences separated out and aged.

Quantity and value differences are breaks and need explaining. Timing differences, where an agent has not yet reflected a settlement you have booked, are expected and should be identified as such automatically by matching against pending settlement rather than raised as exceptions. Conflating the two is what floods a reconciliation queue with items nobody investigates, which is how a genuine break hides for a fortnight. Age every unexplained break, escalate on age rather than only on value, and report the distinction between timing and genuine differences as a quality measure. The mechanics resemble those in [nostro and vostro reconciliation automation](https://digiqt.com/blog/nostro-vostro-reconciliation-automation/), and the cross-functional conflict pattern is the one described in hidden data conflicts across functions.

## How do you handle corporate actions across the network?

By consolidating event data as carefully as position data, since entitlements depend on both.

Corporate action information arrives from agents with varying completeness and terminology, and the entitlement calculation needs the event terms, the position as at record date, and the encumbrance state. Consolidate the event data into the same golden record discipline used for announcements generally, reconcile expected entitlements against what each agent credits, and treat differences as claims to pursue rather than as noise. The full processing chain is the subject of [corporate actions automation](https://digiqt.com/blog/corporate-actions-automation/), and consolidation is where its inputs come from in a sub-custody model.

> **Does your consolidated view distinguish timing differences from genuine breaks automatically?**
>
> [Talk to Digiqt about custody reconciliation design](https://digiqt.com/contact-us/)

## How do you deliver client reporting from it?

Through one canonical model with a rendering layer, never through bespoke extraction paths.

Client reporting requirements proliferate: different formats, different currencies, different groupings, look-through into funds, and delivery through several channels. The failure mode is building a pipeline per client, each with its own transformation logic, which produces dozens of paths that must all be maintained when the underlying data model changes. Instead render from the canonical model: templates define layout, grouping, currency, and content selection, and no client-specific logic enters the consolidation path. Then a new format is a template and a new client is configuration, which is the difference between onboarding in days and in months. Data quality constrains all of it, as set out in this guide to [improving data quality across legacy systems](https://digiqt.com/blog/legacy-skills-shortage-banking-technology/).

### Why does multi-currency reporting cause disproportionate trouble?

Because conversion needs a stated rate, source, and time, and clients compare across periods.

A position reported in a client's base currency requires a conversion, and if the rate source or timing varies between reports the client sees movements that are entirely artefacts. Fix the rate source per client and per report type, record the rate applied on the report, and keep it reproducible. This is the same discipline as recording the applied rate on a transaction in payments, and skipping it produces queries nobody can answer six months later.

## What resilience and concentration risks does the network create?

Dependency on individual agents for market access, with limited substitutability.

Each sub-custodian is a critical third party for the markets it serves, and in some markets alternatives are few. That makes the network a concentration exposure requiring the same discipline as any critical dependency: identify which agents are critical for which markets, assess substitutability honestly, understand the operational effort of switching, and know what happens to assets and settlement capability if an agent fails. The CPMI-IOSCO Principles for financial market infrastructures, published in April 2012, cover central securities depositories and securities settlement systems among other systemically important infrastructures, which sit underneath your agents and form part of the same dependency chain. Data exchange friction with counterparties compounds it, as described in this guide to [slow data exchange between parties](https://digiqt.com/blog/federated-fraud-data-sharing/).

## How should delivery be sequenced?

Instrument mastering first, then positions and cash, then reconciliation, then the harder domains, then reporting.

| Phase | Duration | Deliverable |
|---|---|---|
| Instrument master and mapping | 3 to 5 months | Resolution across agent and market identifiers, versioned |
| Canonical model and adapters | 3 to 4 months | Positions and cash normalised, provenance retained |
| As-at capability | 2 months | Reported and effective time, historical querying |
| Reconciliation with timing separation | 2 to 3 months | Automated matching, timing differences identified, ageing |
| Encumbrance integration | 2 to 3 months | Lending, pledging, restrictions visible in the consolidated view |
| Corporate actions and income | 3 to 4 months | Event consolidation, entitlement reconciliation, claims |
| Tax and fee consolidation | 3 to 4 months | Withholding, reclaim status, fee breakdown |
| Client reporting rendering layer | 3 to 4 months | Templates over canonical model, no bespoke pipelines |

Instrument mastering first is not optional. Every later phase depends on being able to say that two records refer to the same security, and programmes that defer it end up rebuilding their reconciliation once the mapping arrives.

## Which metrics matter?

Identifier resolution rate, normalisation exceptions by agent, break volume split by timing versus genuine, break ageing, and reporting onboarding time.

Report identifier resolution rate and unresolved instruments, since that number caps consolidation completeness. Track normalisation exceptions by agent, which doubles as a data quality scorecard on your network and gives relationship managers something concrete. Report break volume split between timing differences and genuine differences, because the split is the honest measure of reconciliation quality. Age unexplained breaks and escalate on age. Measure time to onboard a new client reporting format, which tells you whether the rendering layer is working. And track the share of client queries answerable from the consolidated record without contacting an agent, since that is the operational value the platform delivers.

Custody consolidation is a normalisation problem wearing a messaging costume. The programmes that succeed invest first in instrument identity and explicit timing, separate expected timing differences from real breaks, and render every client report from one canonical model rather than building a pipeline per relationship.

## Frequently Asked Questions

### Why is custody data consolidation hard when everyone uses standard messages?

Because the same standard is populated differently by each agent and market, so messages are technically valid and semantically inconsistent, which requires normalisation rather than parsing.

### What is the root data problem?

Instrument identity. The same security carries different identifiers across markets and agents, so mapping to one internal instrument is the dependency for every position and transaction.

### Why must timing be explicit?

Because agents report at different local cut-offs, so a consolidated position without a stated as-at time mixes different moments and cannot be reconciled or explained.

### Are timing differences reconciliation breaks?

No, they are expected and must be modelled. A break is a difference that persists once timing is normalised, and conflating the two floods the exception queue.

### Which data items are hardest to consolidate?

Corporate action detail, tax and fee information, and encumbrance. Positions and cash are comparatively simple because the semantics are narrower.

### Why does encumbrance matter to consolidation?

Because a position held is not necessarily available. Lending, pledging, and restrictions must be visible in the consolidated view or downstream decisions will be wrong.

### How do you control client reporting format proliferation?

One canonical data model with a rendering layer, so a new format is a template rather than a pipeline, and bespoke extraction logic never enters the consolidation path.

### What resilience risk does the network create?

Concentration on individual sub-custodians for market access, where a single agent's failure removes your ability to settle or hold assets in that market.

## Sources

- [CPMI-IOSCO, Principles for financial market infrastructures](https://www.bis.org/cpmi/publ/d101.htm)
- [CPMI, Harmonised ISO 20022 data requirements for enhancing cross-border payments](https://www.bis.org/cpmi/publ/d230.htm)
- [CPMI Brief 11, The future of financial messaging: navigating the ISO 20022 migration journey](https://www.bis.org/cpmi/publ/brief11.htm)

Global Custody Data Consolidation Across Sub-Custodian Networks

Let Digiqt design capital account architecture, waterfall configuration, and restatement handling for private markets administration.

Books That Hold Up Under Investor Scrutiny

# Running the Books for Assets That Have No Daily Price

Fund administration for public funds is a high-volume, well-defined problem: securities have observable prices, a daily NAV is computed, subscriptions and redemptions process against it. Private markets administration looks superficially similar and works nothing like it. Valuations are periodic and judgmental, capital arrives when called rather than when subscribed, and the economics of the fund are defined by a partnership agreement whose terms differ per investor because of side letters.

That is why private markets fund administration platforms are built around the investor capital account rather than around a unit price. Everything else in the system exists to keep that account correct.

## What makes this different from public funds?

Six structural differences, each of which changes the data model.

| Dimension | Public funds | Private markets |
|---|---|---|
| Valuation | Daily, observable prices | Periodic, judgmental, sometimes restated |
| Capital flows | Subscriptions and redemptions | Commitments, calls, distributions, recycling |
| Investor economics | Uniform per share class | Varies by investor via side letters |
| Fees | Management fee on NAV | Multiple bases, offsets, step-downs, carry |
| Performance | Return per unit | Multiples and internal rates of return, since-inception |
| Reporting | Standardised, frequent | Template plus bespoke, quarterly, with commentary |

### Why does NAV mean something different here?

Because it is an estimate produced by a process, not a computation from prices.

Net asset value in private markets reflects valuations of holdings that were not traded, produced on a methodology, reviewed, sometimes approved by a committee, and occasionally revised afterwards. The platform must therefore treat valuation as a versioned, sourced, approvable input rather than a market data feed, and it must be able to answer which valuation was used in a given report. That single requirement rules out designs that store a current value and overwrite it.

> **Can your platform state which valuation version produced last quarter's reported capital account?**
>
> [Talk to Digiqt about valuation versioning and capital account design](https://digiqt.com/contact-us/)

## What does the platform have to do?

Nine functions, resolving into the capital account.

| Function | Responsibility |
|---|---|
| Investor register | Investors, vehicles, commitments, transfers, side letter terms |
| Commitment tracking | Called, uncalled, recallable, expired |
| Capital calls | Notice generation, allocation, funding tracking, defaults |
| Distributions | Allocation, characterisation, recycling, withholding |
| Capital accounts | Contributions, allocations, fees, carry, balances by investor |
| Valuations | Per holding, versioned, sourced, approved |
| Waterfall and carry | Tiered allocation of proceeds, clawback tracking |
| Fees | Management fee across bases, offsets, step-downs |
| Reporting | Capital account statements, standard templates, bespoke requests |

### Why is the capital account the core record?

Because it is what the investor owns and what every statement renders.

Every other function is an input to it: a call increases contributed capital, a distribution reduces it or returns profit, a valuation change flows through allocations, a fee reduces it, and carry moves value between limited and general partners. Model it as an append-only ledger of movements with as-at querying rather than as a balance, since investors ask about periods and restatements require recomputation. Institutions that model capital accounts as current balances discover the limitation at the first restatement.

## How do capital calls and distributions work?

Through allocation by commitment, with notices, funding tracking, and the awkward cases modelled.

A call allocates a required amount across investors by commitment proportion, generates notices with payment instructions and deadlines, tracks receipt, and handles the investor who does not fund. A distribution allocates proceeds, characterises them as return of capital or profit, applies withholding where relevant, and may be recallable. The awkward cases are where systems fail: partial funding, defaulting investors with their consequences under the agreement, excused investors for particular investments, and recycling of distributed capital back into available commitment.

### What is equalisation, and why is it unexpected?

The adjustment that brings later investors into the same economic position as earlier ones.

When a fund holds subsequent closes, investors joining later must be treated as if they had invested from the start, which requires them to fund their share of prior calls plus an interest-style adjustment paid to earlier investors. The calculation involves rates, periods, and sometimes fee catch-up, and it must be reproducible because investors check it. Most generic administration platforms do not model this natively, which is why it is frequently performed in spreadsheets and becomes the source of disputes. Build it into the platform with the terms as configuration and the calculation stored.

## How should the waterfall be modelled?

As configurable tiers with stored calculation, never as code.

Distribution waterfalls vary by fund: return of capital, preferred return, general partner catch-up, and carried interest split, applied whole-fund or deal-by-deal, with clawback provisions and sometimes hurdles compounding differently. Model tiers as ordered configuration with parameters, evaluate them per distribution with the inputs and result stored, and support reproduction of any historical calculation. The economics of tiered participation are the same shape as the commission waterfall structures described in this guide to fee structures and waterfall economics.

### Why do side letters break generic models?

Because they vary economics per investor rather than per class.

A side letter may grant a fee discount, a different carry arrangement, excusal rights for certain investments, or reporting entitlements. A platform whose economics are defined at fund or class level cannot express that, so the terms end up maintained outside the system and applied manually, which is both an operational risk and an audit finding. Model investor-specific term overrides explicitly with effective dates, and require every override to reference the document that granted it, since the question at audit is always what the investor was entitled to and on what basis.

> **Are your side letter terms held in the platform or applied manually at allocation time?**
>
> [Talk to Digiqt about investor terms and side letter modelling](https://digiqt.com/contact-us/)

## How do you handle valuation of illiquid assets?

As a versioned process with methodology, source, approval, and restatement support.

Hold valuations per holding per period with the methodology used, the preparer, the reviewer, the approval, and the effective date. Support multiple versions of the same period, because valuations get revised, and record which version was used in each report. Then support look-through where investors require it, which means holding portfolio company financial data with its own vintage and provenance. That data arrives late, in inconsistent formats, and sometimes needs chasing, so treat collection as a tracked workflow rather than an input assumption.

### Why is restatement handling a design requirement?

Because a revised valuation changes allocations, carry, and reported performance after the fact.

When a prior period valuation is revised, capital account allocations change, carry may change, reported multiples and rates of return change, and investors have already received statements based on the old figures. The platform needs to recompute cleanly, retain the prior version, and produce a clear explanation of what changed and why. Designs that overwrite cannot do this, and the manual workaround is a spreadsheet reconciliation nobody can audit. Restatement is not an edge case in this asset class, it is routine.

## What about fund structures and consolidation?

Control assessment per vehicle, because structures determine what consolidates.

Master-feeder arrangements, parallel funds, blockers, and special purpose vehicles all affect what consolidates into what and how investor economics flow. IFRS 10 Consolidated Financial Statements, issued in May 2011, defines the principle of control and establishes control as the basis for consolidation, setting out how to apply the control principle to determine whether an investor controls an investee. For a platform that means the structure is data with effective dating and a documented consolidation basis per vehicle, not a static configuration, since structures change with new vehicles and restructurings. Cash flow presentation follows its own requirements, with IAS 7 Statement of Cash Flows setting the operating, investing, and financing classification framework.

## How should fees be calculated?

Across multiple bases with offsets and step-downs, all versioned.

Management fees may be charged on committed capital during the investment period and on invested or net asset value afterwards, with step-downs at defined dates, offsets for transaction or monitoring fees received, and investor-specific discounts. Each of those is a rule with an effective period, and the combination is where errors occur. Store the fee calculation with its inputs and rule versions like any other financial computation, which is the same discipline described in [interest accrual and fee calculation engines](https://digiqt.com/blog/interest-accrual-calculation-engine/).

## How should investor reporting be delivered?

From one canonical model through a rendering layer, with bespoke requests as templates.

Investors expect capital account statements, standard reporting templates that have become industry practice, performance figures, and increasingly bespoke data cuts for their own reporting. The failure mode is a pipeline per investor request, which multiplies maintenance and guarantees inconsistency between reports. Render everything from the canonical capital account and valuation data, treat each format as a template, and never let investor-specific transformation logic enter the data layer. That approach is the same one that controls format proliferation in [global custody data consolidation](https://digiqt.com/blog/global-custody-data-consolidation/), and the reporting discipline resembles this guide to structuring investor reporting.

## How should delivery be sequenced?

Capital accounts first, then calls and distributions, then waterfall, then valuation versioning, then reporting.

| Phase | Duration | Deliverable |
|---|---|---|
| Investor register and commitments | 2 to 3 months | Investors, vehicles, commitments, transfers, side letter terms |
| Capital account ledger | 3 to 4 months | Append-only movements, as-at querying, restatement capable |
| Calls and distributions | 3 to 4 months | Allocation, notices, funding tracking, defaults, recycling |
| Equalisation | 1 to 2 months | Configurable terms, stored calculation, reproducible |
| Valuation versioning | 2 to 3 months | Methodology, source, approval, multiple versions per period |
| Waterfall and carry | 3 to 4 months | Configurable tiers, clawback tracking, stored calculations |
| Fee engine | 2 to 3 months | Multiple bases, offsets, step-downs, investor discounts |
| Reporting rendering layer | 3 to 4 months | Templates over canonical model, bespoke requests as templates |

Capital accounts before everything else, because every other function writes to them and a platform that models them as balances rather than as movement history will need rebuilding at the first restatement. Period-end discipline matters throughout, and the reconciliation-timing lessons in [cutting close reconciliation time](https://digiqt.com/blog/financial-close-automation-banking/) apply directly to quarterly reporting cycles.

## Which metrics matter?

Reporting cycle time, restatement frequency and cause, allocation exceptions handled manually, equalisation and waterfall reproducibility, and investor query volume.

Report cycle time from period end to investor statements issued, since that is the service investors experience. Track restatements with cause, because a high rate indicates a valuation process problem rather than a platform one. Count allocations requiring manual intervention, which measures how much of the economics the platform actually models. Verify that equalisation and waterfall calculations reproduce identically when re-run, and treat any failure as blocking. And measure investor query volume and the share answerable from the platform without a manual reconstruction, since that is the operational load the system exists to remove.

Private markets administration rewards precision in a small number of places: the capital account as movement history, valuations as versioned approvals, waterfalls and equalisation as configuration with stored calculations, and investor terms held in the platform rather than in a folder of side letters. Get those right and the reporting is rendering. Get them wrong and every quarter becomes a reconciliation exercise.

## Frequently Asked Questions

### How does private markets administration differ from public funds?

Valuation is periodic and judgmental rather than daily and observable, capital moves through calls and distributions rather than subscriptions, and investor terms vary individually.

### What is the core record in the platform?

The investor capital account. Commitments, calls, distributions, allocations, fees, and carry all resolve into it, and every investor statement is a rendering of it.

### What is equalisation and why is it unexpected?

When later investors join at a subsequent close, they must be brought into the same economic position as earlier ones, which requires interest-style adjustments most systems do not model.

### Why is hard-coding a waterfall a mistake?

Because tiers, preferred return, catch-up, and carry vary by fund and are modified by side letters, so the waterfall must be configuration with an audit trail rather than code.

### Why do side letters break generic models?

Because they vary economics per investor, including fee discounts and different carry treatment, so allocations must support investor-specific terms rather than one fund-level rule.

### Why is restatement handling a design requirement?

Because valuations get revised after reporting, which changes allocations, carry, and reported returns, so the platform must restate cleanly and show what changed.

### What does consolidation require in fund structures?

A control assessment per vehicle, since master-feeder and SPV structures determine what consolidates, and IFRS 10 establishes control as the basis for consolidation.

### What should investor reporting be built on?

One canonical data model with a rendering layer, so standard templates and bespoke investor requests are both templates rather than separate extraction paths.

## Sources

- [IFRS Foundation, IFRS 10 Consolidated Financial Statements](https://www.ifrs.org/issued-standards/list-of-standards/ifrs-10-consolidated-financial-statements/)
- [IFRS Foundation, IAS 7 Statement of Cash Flows](https://www.ifrs.org/issued-standards/list-of-standards/ias-7-statement-of-cash-flows/)

Fund Administration Systems for Private Markets and Alternatives

Let Digiqt design inventory accuracy, eligibility modelling, and real-time collateral optimisation for securities financing.

Optimise Collateral You Can Actually Deliver

# Knowing What You Have, What It Can Cover, and What It Costs

Collateral optimisation is usually presented as an algorithm problem, and the algorithm is the easy part. Linear programming over a set of eligible assets and obligations is well understood. What makes securities financing platforms hard is that the inputs are wrong: the inventory does not reflect what is genuinely available, the eligibility schedules exist as PDF annexes interpreted inconsistently, and the position moves during the day while the optimisation ran overnight.

A securities lending repo platform earns its return by fixing those inputs. Get inventory and eligibility right and a simple allocation rule captures most of the available benefit. Get them wrong and a sophisticated optimiser produces allocations that fail on delivery.

## What does the platform have to do?

Four functions, with inventory as the dependency for the other three.

| Function | Responsibility | Failure consequence |
|---|---|---|
| Inventory | What is held, what is available, what is encumbered | Failed deliveries, missed revenue, breached restrictions |
| Trading and matching | Availability, pricing, negotiation, confirmation | Lost opportunity, operational breaks |
| Collateral management | Eligibility, haircuts, allocation, substitution, margin | Over-collateralisation, failed calls, cost |
| Risk and reporting | Exposure, concentration, regulatory reporting | Regulatory findings, unmeasured risk |

### Why is inventory the foundation?

Because availability is computed from many inputs, not stored in one place.

What is available to lend at a given moment depends on settled positions, pending settlements in both directions, positions already lent or pledged, assets in a triparty pool, holdings subject to client restrictions or ring-fencing, securities near a corporate action record date, entity and jurisdictional boundaries, and intraday activity. Any of those missing produces a number that is optimistic, and an optimistic availability figure becomes a delivery failure. Build availability as a real-time computed view with visible components, so an operations user can see why a security is unavailable rather than discovering it at delivery.

> **Can your platform explain why a given security is unavailable to lend right now?**
>
> [Talk to Digiqt about inventory and availability modelling](https://digiqt.com/contact-us/)

## What makes inventory hard in practice?

Encumbrance, restrictions, and timing, all of which change during the day.

| Input | Complication |
|---|---|
| Settled versus traded position | Availability differs by settlement convention and market |
| Already lent or pledged | Must net out, including triparty allocations |
| Client restrictions | Per-client and per-mandate lending permissions |
| Ring-fencing and entity boundaries | Assets in one entity may not serve another's obligation |
| Corporate action proximity | Record dates constrain lending and create manufactured payments |
| Recalls in flight | Position is returning but not yet available |
| Fails and pending buy-ins | Expected position may not arrive |
| Regulatory and internal limits | Concentration and counterparty limits reduce usable inventory |

The corporate action interaction deserves particular attention, since lending across a record date creates entitlement complexity and manufactured payment obligations, which is why the economic position view matters in [corporate actions automation](https://digiqt.com/blog/corporate-actions-automation/).

## How does collateral optimisation actually work?

As constrained allocation, where the constraints do more work than the objective function.

The objective is usually to deliver the cheapest acceptable collateral against each obligation while respecting every constraint. The constraints are the difficult part: per-agreement eligibility schedules, haircuts varying by asset class, rating, and maturity, concentration limits by issuer, sector, and currency, wrong-way risk restrictions, minimum denominations and settlement feasibility, and substitution rights. Encoding those accurately from legal agreements is the real project, and it is frequently done once and left to drift as agreements are amended.

### What is the objective actually?

Cost of collateral delivered, adjusted for operational cost and risk, rather than notional efficiency.

Optimising purely on the theoretical cheapest asset produces high substitution volumes, settlement failures on illiquid instruments, and operational cost that exceeds the funding saving. Include a movement cost so the optimiser prefers stability, exclude assets whose settlement reliability is poor regardless of their theoretical eligibility, and weight for the funding value of retaining high-quality liquid assets, since delivering them as collateral has a liquidity consequence the treasury cares about. The liquidity cost allocation logic sits alongside the supervisory expectation that liquidity costs, benefits, and risks be allocated to business activities, as set out in the Basel Committee's liquidity principles.

### Why does the constraint set matter more than the algorithm?

Because a wrong constraint produces a confidently wrong allocation.

An eligibility schedule transcribed incorrectly means the optimiser proposes collateral the counterparty will reject, which surfaces as a failed call and an urgent manual scramble. Maintaining the constraint set is therefore an ongoing data governance task with a named owner: every agreement amendment must reach the platform, every schedule needs a version and an effective date, and discrepancies discovered at delivery must feed back as corrections. Collateral quality also drifts over time between agreement and delivery, which is the phenomenon examined in collateral quality drift.

## Why must optimisation be real time?

Because intraday margin calls, recalls, and market moves change the answer within hours.

An overnight optimisation cannot respond to a call due at midday, a recall received at ten, or a market move that changes haircut-adjusted values. The practical requirement is not microseconds, it is the ability to recompute an allocation within minutes of a change and to answer availability queries interactively. Design for incremental recomputation rather than full re-optimisation, since recalculating the entire book for one new obligation is both slow and disruptive, producing unnecessary substitutions. Intraday visibility of positions and obligations is the same requirement as in [real-time treasury platform design](https://digiqt.com/blog/real-time-treasury-platform/) and connects directly to intraday liquidity monitoring.

## How do you handle recalls and fails?

As tracked workflows with prioritisation, because the downside is a fail and potentially a buy-in.

A recall arrives because the beneficial owner needs the security, frequently to sell or to vote. Meeting it requires locating a return or a replacement borrow within the settlement window, and missing it creates a fail with cost and potentially a buy-in. Treat recalls as cases with a deadline, an owner, and escalation, prioritise by consequence rather than arrival order, and instrument the fail path so the cost is visible. Fails analysis is also a useful data quality signal, since repeated fails on the same counterparty or instrument usually indicate an inventory or settlement assumption that is wrong rather than bad luck.

> **Are recalls tracked as cases with deadlines, or handled by email and memory?**
>
> [Talk to Digiqt about recall and fails workflow design](https://digiqt.com/contact-us/)

## How do triparty arrangements change the design?

They move eligibility testing and substitution to an agent, and they replace one problem with a reconciliation obligation.

Under triparty, the agent holds the collateral pool, tests eligibility, and performs substitutions, which removes substantial operational load. What remains is your obligation to know what is in the pool, to reconcile the agent's view against your own inventory and exposure, and to understand the eligibility profile the agent is applying. The failure mode is assuming alignment: your platform believes an asset is available while it sits allocated in a triparty pool, and the discrepancy appears when you try to deliver it elsewhere. Reconcile continuously against the agent rather than periodically, which is the same discipline as in this guide to [pledged asset reconciliation](https://digiqt.com/blog/nostro-vostro-reconciliation-automation/).

## What regulatory expectations apply?

Reporting and transparency, haircut standards, and cash collateral reinvestment limits.

The FSB's Policy Framework for Addressing Shadow Banking Risks in Securities Lending and Repos, published in August 2013, sets out thirteen recommendations covering improvements in regulatory reporting and market transparency, minimum standards for haircut methodologies with proposed numerical haircut floors for certain financing transactions, minimum standards on cash collateral reinvestment, and recommendations on central clearing and market infrastructure. For a platform, that translates into concrete requirements: transaction-level reporting capability with the granularity supervisors expect, haircut calculation that follows a documented methodology rather than negotiated convention alone, and controls over how cash collateral is reinvested with limits enforced in the system rather than in policy documents. Where transactions clear centrally, the infrastructure standards in the CPMI-IOSCO Principles for financial market infrastructures apply, covering central counterparties among other systemically important infrastructures.

### What does reporting require from the platform?

Transaction-level records with the attributes and lifecycle events supervisors expect, produced without reconstruction.

Build reporting from the transaction store rather than assembling it from downstream systems, capture lifecycle events including modifications, substitutions, and terminations rather than only inception, and retain the ability to reproduce a submitted report. Counterparty identification, collateral detail, haircut applied, and re-use status all need to be first-class fields rather than derived at reporting time, because deriving them later is where inconsistencies enter.

## How do you handle counterparty risk in the platform?

By evaluating exposure continuously against limits, with collateral quality included.

Exposure is not notional, it is the difference between obligation and haircut-adjusted collateral value, and it moves with markets. Compute it continuously, evaluate against counterparty and concentration limits before allocating, and monitor collateral quality rather than only quantity, since a fully collateralised position secured by concentrated, correlated, or illiquid assets is not as safe as the coverage ratio suggests. Counterparty assessment needs to combine credit, collateral, and concentration in one view rather than three, which is the argument in [monitoring credit, collateral and concentration together](https://digiqt.com/blog/counterparty-credit-risk-system/). Operational friction in collateral processes is itself a risk, as described in collateral friction operating controls.

## How do you measure the benefit honestly?

Against a documented baseline and counterfactual, net of operational cost.

Optimisation benefit is easy to overstate, because the natural comparison is against a badly chosen baseline. Record what the previous allocation approach would have delivered for each obligation, value the difference using consistent funding assumptions, and subtract the operational cost of additional substitutions and settlements. Report the net figure with the assumptions stated. Then track realised versus projected benefit, since projections built on theoretical eligibility routinely exceed what the platform can actually deliver once settlement feasibility and counterparty behaviour are included.

## How should delivery be sequenced?

Inventory, then eligibility, then simple allocation, then optimisation, then real time.

| Phase | Duration | Deliverable |
|---|---|---|
| Inventory and availability engine | 4 to 6 months | Computed availability with visible components and encumbrance |
| Agreement and eligibility digitisation | 3 to 5 months | Machine-readable schedules with versions and owners |
| Exposure and limit monitoring | 2 to 3 months | Continuous haircut-adjusted exposure against limits |
| Rules-based allocation | 2 to 3 months | Deterministic cheapest-eligible allocation, measurable baseline |
| Optimisation engine | 3 to 4 months | Constrained optimisation with movement cost |
| Intraday recomputation | 2 to 3 months | Incremental response to calls, recalls, and market moves |
| Recall, fails, and triparty reconciliation | 3 to 4 months | Case workflow, agent reconciliation, cost visibility |
| Regulatory reporting | 2 to 3 months | Transaction-level lifecycle reporting from the source store |

Rules-based allocation before optimisation is deliberate. It delivers a measurable baseline, it captures a large share of the benefit, and it exposes the data quality problems that would otherwise be blamed on the optimiser.

## Which metrics matter?

Availability accuracy, eligibility exception rate, allocation cost versus baseline, substitution volume, fails and recall performance, and reconciliation breaks.

Report availability accuracy, meaning how often a security shown as available could actually be delivered, since that number is the platform's credibility. Track eligibility exceptions discovered at delivery, which measures the quality of your digitised schedules. Report allocation cost against the documented baseline, net of operational cost. Watch substitution volume, because excessive churn indicates an optimiser without a movement cost. Measure recall fulfilment within window and fails with their cost. And report reconciliation breaks against triparty agents and custody records with ageing, as those breaks are where inventory accuracy quietly erodes.

Collateral optimisation rewards data discipline over mathematics. The institutions that capture the benefit spent their first year making availability computable and eligibility machine-readable, then found that a straightforward allocation rule over correct inputs beat a sophisticated optimiser over wrong ones.

## Frequently Asked Questions

### What does a securities financing platform have to do?

Maintain accurate inventory, trade and match, manage collateral including optimisation and substitution, and produce risk and regulatory reporting. Inventory accuracy underpins all of it.

### Why is inventory the foundation?

Because availability is a computed answer, not a stored one. It depends on settled and pending positions, restrictions, pledges, ring-fencing, and corporate action records.

### What does collateral optimisation actually optimise?

The cost of collateral delivered, subject to eligibility schedules, haircuts, concentration limits, and operational feasibility. The constraint set matters more than the algorithm.

### Why does it need to be real time?

Because intraday margin calls, recalls, and market moves change the answer within the day, and an overnight optimisation cannot respond to a call due in an hour.

### What makes recalls operationally risky?

A recall that is not met on time can lead to a fail and potentially a buy-in, so recall workflow needs prioritisation, tracking, and escalation rather than email.

### How do triparty arrangements change the design?

They move eligibility testing and substitution to an agent, which reduces operational load and requires your platform to reconcile against the agent rather than assume alignment.

### What regulatory expectations apply?

The FSB's policy framework for securities lending and repos covers reporting and transparency, minimum haircut standards including proposed numerical floors, and cash collateral reinvestment standards.

### How do you measure optimisation benefit honestly?

Against a documented baseline and counterfactual, valuing the collateral actually delivered versus what the previous approach would have delivered, net of operational cost.

## Sources

- [FSB, Policy Framework for Addressing Shadow Banking Risks in Securities Lending and Repos](https://www.fsb.org/2013/08/r_130829b/)
- [CPMI-IOSCO, Principles for financial market infrastructures](https://www.bis.org/cpmi/publ/d101.htm)
- [BCBS, Principles for Sound Liquidity Risk Management and Supervision](https://www.bis.org/publ/bcbs144.htm)

Securities Lending and Repo Platform With Collateral Optimization

Let Digiqt design register architecture, transfer controls, and asset servicing for regulated tokenisation.

Tokenise The Asset, Keep The Wrapper

# Putting Real Assets on a Ledger Without Losing the Legal Wrapper

Tokenisation programmes usually start with the token and work outwards, which is why so many stall at the point where a lawyer asks what the holder actually owns. A token is a record on a ledger. Whether it represents legal title, a beneficial interest, a contractual claim against an issuer, or merely evidence of an entry in a register held elsewhere is a legal question with entirely different engineering consequences.

A tokenized real world assets platform that reaches production is therefore designed from the legal structure inwards. The ledger is the easy part, the register is the important part, and asset servicing is where most of the effort goes.

## What is actually being tokenised?

Almost never the asset itself, and the difference determines the architecture.

| Structure | What the token is | Design consequence |
|---|---|---|
| Direct title recorded on ledger | The authoritative record of ownership | Requires legal recognition of the ledger as the register |
| Token as evidence of a register entry | A representation, register is authoritative | Ledger and register must reconcile continuously |
| Token as a claim on an issuer | A contractual right | Issuer credit matters, insolvency analysis required |
| Token representing a fund interest | Units in a collective vehicle | Fund rules, NAV, subscription and redemption mechanics |
| Token as a wrapper over a custodied asset | Interest in an asset held by a custodian | Custody arrangement and segregation are central |

### Why does the legal wrapper decide everything?

Because it determines who owns what if the platform fails, and what the holder can enforce.

If the ledger is the authoritative register in law, a transfer on the ledger is a transfer of ownership and the platform is systemically critical to the asset. If the ledger merely mirrors a register held by a transfer agent, then the register governs and the ledger is a convenience that must be reconciled. Both are viable, and the failure mode is building the second while telling investors it is the first. Settle this before designing anything, because the answer changes custody, recovery, dispute resolution, and what happens in insolvency.

> **In your structure, if the ledger and the register disagree, which one is right?**
>
> [Talk to Digiqt about tokenisation structure and register design](https://digiqt.com/contact-us/)

## Which asset classes are realistic?

The illiquid and operationally heavy ones, because that is where the current process is expensive.

| Asset class | Benefit potential | Reason |
|---|---|---|
| Private funds and private credit | High | Manual subscription, transfer, and reporting today |
| Real estate interests | High | Fractionalisation and transfer friction |
| Money market fund units | Moderate to high | Collateral mobility and intraday movement |
| Corporate bonds | Moderate | Already reasonably efficient, gains in issuance and small denominations |
| Listed equities | Low | Existing infrastructure is efficient and cheap |
| Commodities | Variable | Depends entirely on the underlying custody arrangement |

### Why do liquid assets gain least?

Because their existing settlement is already fast, cheap, and legally settled.

Tokenising an instrument that already settles reliably through a depositary adds a parallel process with new legal questions and no material efficiency gain. The genuine opportunity is where investors currently wait weeks for a subscription, where transfers require signed paperwork, and where reporting is assembled by hand. Choose the asset class on that basis rather than on which one is easiest to demonstrate, and be honest internally about which programmes are exploration rather than value delivery. That candour is the point of this assessment of [blockchain use cases versus marketing hype](https://digiqt.com/blog/atomic-settlement-dvp-dlt/).

## What does the platform need to do?

Nine functions, with the register rather than the token at the centre.

| Function | Responsibility |
|---|---|
| Issuance | Create the instrument, its terms, and its initial allocation |
| Register | Authoritative record of holders, holdings, and entitlements |
| Transfer control | Enforce eligibility, restrictions, lockups, and limits |
| Asset servicing | Income, corporate actions, fees, tax |
| Valuation | Pricing or NAV, at a defined frequency with a source |
| Investor eligibility and onboarding | Suitability, jurisdiction, accreditation, AML |
| Custody | Underlying asset and token or key custody |
| Secondary transfer or market | Matching, settlement, price formation |
| Reporting | Holder statements, regulatory reporting, tax documentation |

### Why is the register the core rather than the token?

Because entitlements, not tokens, are what holders are owed.

Income distributions, voting, tax reporting, and redemption all operate on the register of who held what and when. A platform designed around token transfers and lacking a proper register discovers this at the first distribution, when it needs a position as at a record date including transfers in flight. Build the register with as-at querying, full history, and reconciliation to the ledger, and treat the token as a transfer mechanism rather than as the system of record unless the legal structure genuinely makes it so.

## How do transfer restrictions work?

Through eligibility rules enforced at transfer, plus off-ledger controls for what the ledger cannot see.

Regulated instruments carry restrictions: eligible investor categories, jurisdictional limits, holding period lockups, maximum holder counts, minimum denominations, and sanctions constraints. Enforce what can be enforced at transfer through whitelisted addresses tied to verified investors, and accept that some conditions depend on facts the ledger does not hold, such as an investor's current accreditation status or a sanctions listing published minutes ago. That means an off-ledger control layer with the authority to block, freeze, or reverse where the rules permit, which brings you back to the correction mechanism question and to sanctions screening at the point of transfer, as covered in this guide to [sanctions screening and unpayable claims](https://digiqt.com/blog/trade-compliance-screening-system/).

### Why are on-ledger controls insufficient alone?

Because eligibility is a fact about the world, not a property of an address.

An address whitelisted last quarter may belong to an investor whose accreditation lapsed, whose jurisdiction changed, or who has since been sanctioned. On-ledger enforcement is fast and deterministic and it can only apply the state it holds, so the platform needs a process that keeps that state current and a mechanism to act between updates. Design the refresh cadence deliberately and monitor the staleness of eligibility data, since that staleness is your actual compliance exposure.

## How do you handle asset servicing?

As an off-ledger process reconciled to the ledger, because the underlying asset does not know it has been tokenised.

Income arrives, corporate actions occur, fees accrue, and tax must be withheld, all determined by the underlying asset and its market. The platform must compute entitlements from the register as at the correct date, execute distributions to current holders, handle events the token model cannot represent, and reconcile throughout. The events that break naive designs are the awkward ones: a restructuring that changes the instrument, a partial redemption, a fractional entitlement, a stock distribution where the new instrument is not tokenised. Model an escape hatch for those rather than assuming the token schema covers everything, and note that the entitlement discipline is exactly that of conventional custody, as set out in [corporate actions automation](https://digiqt.com/blog/corporate-actions-automation/).

> **What happens on your platform when the underlying asset does something the token schema cannot represent?**
>
> [Talk to Digiqt about asset servicing design for tokenised instruments](https://digiqt.com/contact-us/)

## Where does custody sit?

In two places, both requiring segregation and insolvency analysis.

Custody of the underlying asset follows conventional arrangements, with the usual questions about segregation, title, and what happens if the custodian fails. Custody of the token, meaning control of the keys that can transfer it, is a distinct problem: whoever holds the keys can move the asset, so key custody is ownership control in practice regardless of what the register says. Use hardware-backed key management, define quorum arrangements for administrative actions, plan for key loss and compromise with recovery arrangements agreed in advance, and analyse whether client tokens are segregated from the platform operator's own in insolvency. The key custody design sits in [HSM and key management architecture](https://digiqt.com/blog/hsm-key-management-financial/).

## What prudential treatment applies to banks?

A dedicated Basel Framework chapter, with tokenised traditional assets treated as a distinct category.

The Basel Committee published its standard on the prudential treatment of cryptoasset exposures in December 2022, creating a new chapter of the consolidated Basel Framework covering cryptoasset exposures with an implementation deadline of 1 January 2025, and spanning three categories: tokenised traditional assets, stablecoins, and unbacked cryptoassets. The commercial implication for a tokenisation programme is direct: how your instrument classifies affects the capital a bank holder must hold against it, which affects whether banks will buy it. Involve treasury and capital management early, since a structure that looks elegant and classifies unfavourably will struggle to find bank demand. Where the instruments settle on a market infrastructure, the CPMI-IOSCO Principles for financial market infrastructures set the framework for that infrastructure.

## How do you handle valuation and NAV?

With a defined source, frequency, and process, particularly for illiquid assets.

Tokenisation makes transfer easy and does not make an illiquid asset liquid or a hard-to-value asset easy to value. Define the valuation source, the frequency, the responsible party, and the process for stale or contested valuations, then publish the basis alongside the number. Two failure modes recur: a token trading at a price disconnected from a quarterly NAV, and a secondary transfer priced off a valuation the parties did not understand. Both are avoidable with disclosure and neither is solved by the ledger. Fractionalisation raises the same question in a different form, since a small holder needs the same valuation clarity as a large one.

## What makes a secondary market real?

Eligible buyers, price formation, working transfer processing, and settlement finality.

A token that can technically move is not a market. A market requires a population of eligible buyers who can be onboarded quickly, a mechanism for price discovery, settlement that is final in law, and a transfer process that completes without manual intervention. Many tokenisation projects deliver the technical transfer capability and no market, which produces an instrument that is theoretically transferable and practically as illiquid as before. Decide early whether you are building liquidity or operational efficiency, because they need different investments and the second is more often achievable. Settlement mechanics for the transfer leg are covered in [atomic settlement and delivery-versus-payment](https://digiqt.com/blog/atomic-settlement-dvp-dlt/).

## How should delivery be sequenced?

Legal structure, then register, then servicing, then transfer, then market.

| Phase | Duration | Deliverable |
|---|---|---|
| Legal structure and register authority | 3 to 5 months | What the token is, which record governs, insolvency analysis |
| Register and as-at entitlement engine | 3 to 4 months | Holders, history, as-at queries, ledger reconciliation |
| Investor onboarding and eligibility | 2 to 3 months | Verification, accreditation state, refresh cadence |
| Asset servicing | 3 to 5 months | Distributions, corporate actions, tax, escape hatch for exceptions |
| Transfer control | 2 to 3 months | On-ledger enforcement plus off-ledger controls and freeze capability |
| Custody and key management | 2 to 3 months | Asset and token custody, quorum, recovery, segregation |
| Secondary transfer capability | 3 to 4 months | Matching, settlement, price basis, reporting |

Asset servicing before transfer capability is deliberate. A platform that can transfer tokens and cannot pay a distribution correctly has automated the easy half and left the part investors actually care about manual. Multi-party governance of the platform itself needs settling early too, as discussed in [multi-party data sharing and consortium models](https://digiqt.com/blog/federated-fraud-data-sharing/), and the transparency benefits that genuinely accrue are the kind described in [blockchain for process transparency](https://digiqt.com/blog/atomic-settlement-dvp-dlt/).

## Which metrics matter?

Register and ledger reconciliation breaks, servicing accuracy, eligibility data staleness, transfer failure rate, and onboarding time.

Report reconciliation breaks between register and ledger with ageing, since any break means somebody's holding is ambiguous. Track servicing accuracy, meaning distributions and corporate actions executed correctly and on time. Measure eligibility data staleness, which is your compliance exposure between refreshes. Report transfer failure rate by cause, distinguishing eligibility blocks, which are the control working, from technical failures. Measure investor onboarding time, because that determines whether a secondary market can function. And track manual interventions per servicing event, since that is the operational efficiency the programme was meant to deliver.

Tokenisation delivers real value in places where the current process is manual and slow, and delivers very little where existing infrastructure already works. The programmes that succeed settle the legal question first, build a proper register rather than relying on the token, and treat asset servicing as the main engineering effort rather than an afterthought.

## Frequently Asked Questions

### Is the token the asset?

Rarely. In most structures the token evidences a claim or an interest, with the asset held under a legal arrangement. What the token legally is determines everything else in the design.

### Which asset classes benefit most from tokenisation?

Illiquid and operationally heavy ones such as private funds, private credit, and real estate, where the current process is manual. Liquid instruments already settle efficiently.

### What is the core of the platform?

The register of holders and entitlements. The token is a representation, and if the ledger and the legal register can disagree, the register is what matters.

### How are transfer restrictions enforced?

Through whitelisting and eligibility rules applied at transfer, combined with off-ledger controls, since on-ledger checks cannot verify facts that live outside the ledger.

### What breaks when the underlying asset does something unusual?

Asset servicing. Corporate actions, restructurings, and fee events frequently cannot be represented in the token model, so an off-ledger process must handle them and reconcile.

### Where does custody sit?

In two places: custody of the underlying asset and custody of the token and its keys. Both need segregation, insolvency analysis, and key management arrangements.

### What prudential treatment applies to banks?

The Basel Committee's cryptoasset standard creates a chapter covering tokenised traditional assets, stablecoins, and unbacked cryptoassets, with implementation from January 2025.

### What makes a secondary market real rather than theoretical?

Eligible buyers, price formation, settlement finality, and a transfer agent process that works. A token that can technically move is not a market.

## Sources

- [BCBS, Prudential treatment of cryptoasset exposures](https://www.bis.org/bcbs/publ/d545.htm)
- [CPMI-IOSCO, Principles for financial market infrastructures](https://www.bis.org/cpmi/publ/d101.htm)

Posts tagged with#Capital Markets